Preserve Slack artifact identity across corrections by 3mdistal · Pull Request #2134 · BuilderIO/agent-native

3mdistal · 2026-07-14T22:59:39Z

Summary

persists the participant-visible Slack reply and provider delivery references only after a successful send
retains a compact, verified Content artifact identity ledger so later thread corrections can target the same record even after a rename
rehydrates delivered Slack text and stable artifact IDs for the agent without replaying raw tool results
teaches Content to distinguish update, add, supersede, and create intent while keeping verified Requester identity separate from a named Assignee
includes a core package changeset and a Content user-facing changelog entry

Verification

Core Slack, webhook, thread-context, and artifact tests: 122 passed
Content correction-semantics contract tests: 2 passed
Core typecheck: passed
Content typecheck: passed
formatting and diff checks: passed

Manual QA gate

The real Slack correction story remains a post-deploy test because this workspace has no preview Slack bot or webhook environment:

Create one disposable Design Ask from private #test-content-app.
Rename the created record in Content.
Correct it implicitly in the same Slack thread.
Verify the original Content ID is updated without a duplicate, Requester remains the verified Slack sender, and the named person resolves to Assignee.
Replay the correction once to verify idempotency.

No production data was mutated while preparing this PR.

Scope separation

BuilderSync publication, preview relay, hosted authorization, and Builder UI work remain exclusively in #2130. This PR contains exactly the 14 Slack/Content correction paths.

github-actions · 2026-07-14T23:03:05Z

Here's a visual recap of what changed:

Open the full interactive recap

builder-io-integration

Builder reviewed your changes and found 3 potential issues 🟡

Review Details

Incremental Code Review Summary

The latest commit addresses the three prior findings: marker payloads now use dot-safe base64url encoding, continuation persistence has been added after confirmed delivery, and the org-secret concern is covered in the updated continuation/auth flow. I verified those changes and resolved the three prior review threads. New review found remaining delivery-state and presentation issues in asynchronous and misconfigured-provider paths. This remains Standard risk because these paths affect duplicate sends, participant-visible history, and correction replay.

New Findings

🟡 MEDIUM — A continuation that was successfully delivered can be redelivered if thread persistence fails afterward, because the persistence exception enters the generic reschedule path.

🟡 MEDIUM — Several adapters still return no receipt on missing credentials, and the webhook handler treats that as a completed run rather than a delivery failure with fallback/retry handling.

🟡 MEDIUM — The HMAC marker is appended to A2A final response text and then forwarded verbatim through continuation adapters, exposing an opaque machine marker in user-facing Slack/Telegram replies and persisted delivery text.

🧪 Browser testing: Skipped — PR changes integration/backend logic, tests, skills, and changelog files without user-facing browser UI impact.

Preserve Slack artifact identity across corrections

c490213

This comment has been minimized.

Sign in to view